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ABSTEAGT 


A personnel data Base consists of integrated data 
about persons of any organization, A retrieval system 
retrieves information from this data base. The informa- 
tion may be either of a single individual or about a group 
of people. This system has been developed to retrieve in- 
formation from a relational data base containing data about 

Army Officers, The computer system chosen for this data 
base is TDG-316, The system is based on disk* This project 
was taken up as a part of data base project group. The 
other parts being 

(a) Building a Bata Base 

(b) Data validation 

All the systems are written in the Basic Assembly Language 
(BAL) of the TDG-316. 



1. IHTRODUCTIOE 


This information retrieval system works on a perse- 

A 

nnel data base developed at IIT'Zanpur as a project on 
' TDC-316 comp-ater. A personnel ,data base has data about 
persons. In this case the persons chosen are amy officers 
For management of army officers, there is a requirement of 
storing and retrfeving a large amo\int of data in an effi- 
cient manner. The old technique of storing data in multi- 
ple files, each suitable for particular application is a 
cumbersom and inefficient tectinique. The modern data base 
with its management techniques is an ideal choice for work- 
king on such data. Out of the type of data bases available 
a relational data base offers the best scheme for flexibi- 
lity and working in an integrated fashion. This particular 
data base and retrieval system is b.ased on the relational 
approach. 

There are large number of terms being used in data' 
bases. The terms and their meanings, as applicable in 
this stu(^ are given in the succeeding paragraphs. The 
terms definitions are generally as per Computer Beta Base 
Organization by MARTIN and ifi^om- BATE. 

Bata Base 

A data base may be defined as a collection of inter- 
related data stored together with as little redundancy as 
possible to serve one or more applications in an optimal 
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fashion. The data are stored so that they are -indepen- 
dent of programs which use the data, A common and con- 
trolled approach is used in adding new data and in modi- 
fying and retrieving existing data within the data "base. 

An integrated data base contains data for many 
applications. It is a repository of information needed 
for running some organization. In our case the organi- 
zation is the amy. A data base may be organized for 
batch processing, real time processing or in-line proce- 
ssing where single transaction is completed one at a time, 
without the constraints of real time processing. Our 
system approxima.tes to IMLINB processing. 

Advantages of having data bases against the con- 
ventional tape library systems have been explained by 
various authors. The biggest advantage is having contro- 
lled minimal redundancy with its accompaniment of 

low cost storage 
single updating run 
consistancy. 

One of the most important characteristics of data bases is 
the case of restructuring data storage without change in 
application programs. This is termed Data Independence. 
Data Indenendence 

It implies that data and the programs which use this 
data, are mutually independent and each may be changed 
without affecting the other. The application programmer is 
insulated from changes in data storage. He need not know 
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how aad where they are stored. This also gives some measure 
of security and privacy. Unantic ip a. ted questions may he 
asked from the data base. The application programs are 
interested in logical organization. 

Logical and Physical View 

A logical data description refers to the manner in 
which a programmer sees the data. It may or may not (more 
often not) coincide with a physical data description which 
refers to the manner in which da.ta is stored physically on 
devices. Programmer sees the logical relationships and 
logical data structures. He requires a logical chain of 
records, which may not he the physical chain. Software 
converts programmers logical statements to the physical 
reality* 

SCHEMA 

The logical description of a da,ta hase used hy the 
data hase software is called SCHEMA. A schema is a chart 
of the types of data that are used. It gives the names of 
the entities and their attributes and specifies the 
relations between them. It is a frame work into which the 
values of data items can he fitted. The values may change 
from tii^e to time. Any particular set of values in the 
schema is called an *Inst8nce of Schema'. Schemas are 
often drawn in the form of block diagrams. They are also 
called 'Data Model*. 



4 


The following terms which have been used in defining 
SCHEMA are themselves defined. 

Data Item 

A data item is the aaallest unit of named data. It 
is referred to as a field or da.ta element . 

Data Aggregates 

It is a collection of data items within a record which 
is given a name and referred to as a whole, e.g. , Data may 
consist .of year, month and day. 

Record 

A named collection of data items or data aggregates. 

An application program reads a logical record. 

File 

A file is a named collection of all occurrences of a 
given type of record. 

Entity 

Items about which we store information are referred 
to as entities. An entity is a tangible object such as a, 
persorv a part of inventory or a plaice. It may be non- 
tangible such as an event, a, customer accotint. We record 
the properties of the entities. The information is called 
an entity record. It is called a logical record by appli- 
cation programme and a stored record by the physical 
storing mechanism. 
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At tr ibut e s 

The property of an entity is called an attribute. 

These attributes ha.ve values such as personal number, 
rank, address, account nTimber etc. These attributes 
are stored as data items in byte stjplhgsij- 
PI AT EIIIB 

The rorrelation between values, attributes and en- 
ties is normally most easily stored in a fixed sequence 
in two dimensional tabular form, called a flat file. A 
scheme of flat file is shown in the Figure 1-1, 

Bach row of the table represents one entity, Bach 
colTomn of the table refers to an attribute. The name of 
the attribute is given in the top of the table, iln attri- 
bute the value of which identifies an entity uniquely is 
called an identifier or key . In the case shown, -personal 
number acts as the key. The grouping of data items repre- 
sents a relationship between these items and such a rela- 
ted set of values is also called a tunle . 

Subschema, 

A subschema is an application programmer’s view of 
the data he uses. Many subschemas can be derived from 
a single schema. The application programmers do not 
necessarily see the schema. With the subschema, the schema 
and the physical organizs.tion, there are three -view of data. 
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A FLAT FIIE 



Attribute 

1 

Attribute 

2 

Attribute Attribute 

3 4 

Key 

Fersonal lo. 

Kame 

Date of 
birth 

Addre ss 

Entity 

1 

IC-001 

Ravi 

12 Dec. 1940 

XX 

2 

IC-610 

Madhav 

15 Sept. 1933 

XX 

3 

IC-200 

DeepaK 

8 Marc. 1948 

XX 

4 

10-300 

Ram 

1 Apr. 1950 

XX 

5 

lC-400 

Raji 

2 Jun. 1956 

XX 


Fig. 1-1 
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(1) Subschena : application prograinmer * s view 
also called Data Sub Model. 

(2) Schema or G-lobal logical data base descrip- 
tion as seen by the data base administrator. 

Also called DATA MODEL, 

(3) Physical Data Base Description: A cha,rt of 
the physical layout of the data on storage 
devices seen by systems programmers. 

The system software provides mapping between these 
different views. Thus a data base managemen" system will 
have a presentation as shown in Figure 1-2. (MijRTIN 
Figure 7-2.) 

This system ensures logical data independence which 
means that the overall logical structure of the data may 
be changed without changing the application programs. 

It also has physical data independence which means 
that the physical storage may be changed without changing 
either the overall logical structure of the data or the 
application programs. 

Relational Data Base 

Once the logical data ihdependence has been achieved 
the over riding consideration in design of daf a base is 
the convenience of the majority of ai3plioa.tton programmers. 
The description of data shotild be under sto6d easily by the 
users, such as a description is achieved by using two dimen- 
sional flat tables. Any complex representation such as 
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storage 


Figure 1-2 
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tree or plex structures can also "be reduced to a flat file 
representation by a simplification x^rocess called norma- 
lization. A flat file tabular representation is called a 
re lati on . . A data base constructed using relations is 
called a relational data base. 

It should be possible to extract subsets from such 
a table and also to join such subsets giving a flexibility 

00 the user in information retrieval. This retrieval will 
consist of selecting different columns for an entity and 
the ability to combine them. The characteristics of such 

1 data base will be 

1. Bach entity in. a relation represents one 
data item. 

2. The relations are column homogeneous i.e., 
all items in a column are of same type. 

5. Bach column or attribute has a distinct 
name. 

4. Bach row is distinct. Duplicate rows are 
not allowed. 

Information Retrieval 

Information retrieval from such a base can be done 
in any seq^uence of rows and columns. Each entity has 
one identifier attribute which is unique. In some relation 
there may be more than one attribute to identify the entity. 
These identifiers are also called keys. These keys have two 
properties; 
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(a) ■unique identifieation 

(b) non-redundancy. 

Where there are more than one keys, one of them is 
termed as primary key. Most of the search is done on pri- 
mary key. In our system, an approach akin to relational 
caJLculus is adopted. The user simply defines the results 
he •WEm.ts and leaves the system to decide what operations 
are necessary to extract that information. It is like 
defining a new relation which is to be derived from the 
existing relations in the ba,se. Sometimes it is advocated 
that binary relations (relations having binary tuples) 
offer the maxim'um flexibility for random queries in an 
unanticipated fashion. This however increases the house 
keeping jobs of the system software. Our data base is - 
not based on binary relation, however, a lange number of 
queries of unanticiproted types can be answered. 

Army Officers Data Base 

The army has a large number of officers. Maxim'um 
possible information on each has to be kept. At present 
about 150 different attributes can be easily identified. 

The users are the various departments of the army which are 
interested in reports as below. 
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(a) strength of officers in the army 

(h) strength of officers in the various corps 

(c) pay and accotmts 

(d) qualification 'n ■i--' , . 

(e) pensions 

(f) recruitment throu^ various academies 

(g) selection of officers for various courses 
and appointments. 

Most of the army officers movements are done corpswise 
1 . s such it is heneficial to have a relation ■which is organi- 
zed with corps as primary key. But this key will be repeated 
this type of file is called an in 3 $:ertecl file. Other rela- 
tions are organized personal number as the primary key. 
Every officer has a unique personal number. The user depar- 
tments give their subschemas, which consist of two or more 
attributes. The system extracts this informa.tion from the ; 
da,ta base. The system developed here does not do the pay 
and accounting though this can also be done with slight 
modifications. This information system prepares lists of 
officers as out put. Eor manipulation and calculations, ' 

simple programs have to be written. The system is a pilot ■ 
system for a personnel data ba,se developed specifically 
on TDC-316, Due to limitation of time and the availability 
of computer simplicity in design of programs has been the 
key. The system can be easily expanded to suit any unanti- i 
cipated query requirement. This thesis has been organized 
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manner: 

Part I: System Constraints and General 
Consider a,tions. 

Part II: Description of Rela,tions and Common 
Data Structures. 

Pa,rt III: Query Translation. 

Part lY: Access Mechanism. 

Part V: Processing and Output. 

Program listing and instructions for working the system 

have been included as anpendices. 



2. SYSTEM COMSTRf^IFTS 


Introduction 

The retrieval system starts from the projection of the 
query. The query has to he recognized, analysed and then 
used to define data structures which are used hy seek and 
processing routines. The information is then located, pro- 
cessed and put in the output buffer. The output routines 
then give a print out as per the subschema of the user. 

Such a system can be as powerful as desired with a 
very wide range of features. These again are controlled by 
the following factors; 

(a) The computer used 

(b) The language used 

(c) The memory available 

(d) Complexity of the system 

(e) System speed 

(f) Generality of the system 

(g) Time available to generate the system. 

These factors as applicable to this system are described 

in the following paragraphs. 

Oomnuter 

The computer to be used is TDO-316 with the following 
configuration: 
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1. cru 

2. Memory 28E 

3. Card reader 

4. Disc lack - 7.6 M bytes 

5. Printer 

6. Paper tape reader 

7. Paper tape punch 

8. Key board /tele type. 

This configuration can have only card reader/keyboard/paper 

tape 

as the input device and line printer/paper tape punch as 
output device. The system is disc based. 

La nguage 

There are two languages available: 

1, PORTRID 

2. Basic assembly language, BAL, 

The BAE assembler is not relocatable and as such P0R5EM 
and BAI, routines cannot be called by each other. PORTR/JK' has 
an added restriction in use of disc. It can access the disc 
only in the serial mode. It was decided to use BAifc as the 
language for system development. 

Memory Available 

The main memory available with BAD is 28K words. Bach 
xrord in TDC~316 consists of 2 bydes of 8 bits each, Bach 
byte is separably addressable. The ’lower byte has even 

address. For word addressing the location counter has to be 
incremented by 2. The secondary memory available is a disc 
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pack of 7.62 M lytes. There are 202 -usable tracks/cylinders, 
10 surfaces and 10 sectors/surf ace/track, Sach sector of 
disc can store 256 bytes. Every sector is addressable through 
a surface and sector register word in the disc controller. 
CoiniDlexitv of System 

The complexity of the ^stem is judged by the n-umber 
and type of ^ftware routines, then lengths and the facili- 
ties provided. The levels of nesting of subroutines, gene- 
rality and sophistication of input/ output requirements are 
other factors. 

This system is totally modular in construction. The 
routines are kept sma.ll in size and designed for optim-um 
efficiency in working time and space. The number of pointer 
and fla.gs have been kept to a minimiAm 
System S-peed 

The algorithms have been designed to exploit all the 
features of the assembler to reduce working t ime and space. 

The movement of data between the memory and the disk is kept 
at the bare minimum. This has been achieved by avoiding 
creation of intermediary files on disc while processing 
conditions, 

Sxamnle 

Let us say the set of conditions is as per the table 
given below. 
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Sr. No. 

Relation 

5*1611 

( attribute ) 

Condition 

Value 

1 

R1 

PI (RIMK) 

EQUAL 

G/aPT. 

2 

R1 

F4 (ARM) 

l.T. 

Arty 

3 

R1 

F6 (Service) 

G.T. 

5 years 

'4- 

R2 

F2 (Qual) 

EQUAL 

B.Sc. 


R2 

F8 (POBTTS) 

GTE 

4 

6 

R3 

F15 (Age) 

L.T. 

26 year 


Table 2—1, Set of Conditions 


The conditions show that we have to process 5 Rela- 
tions R1,R2,R3, We can do either of the following 

(a) Search relation R1 completely. Create an 
intermediary file containing list of officers 
meeting conditions 1,2,3 pertaining to Relation 
1. Then we process Relation R2 and extract 
another intermediary file II. Wnich will have 
a list of all officers satisfying conditions 

1 to 5. Rinally we obtain the final list or 
file after Relation 3, In this case two inter- 
mediary files will ha-ve to be created on disc. 

(b) The second approach will be to process relations 
R1,R2,R3 simultaneously. Processing of every 
officers record is through a filter made up of 
JOIN or logical ilTP of all the conditions, iin 
output record is created only when all six 
conditions are satisfied, No intermediary files 
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are created. 

In the second approach., movement between the memory and 
disc is cut down. However, space is required for. processing 
more than one relation in the memory. It will he seen than 
in the absence of inverted files, no extra space is required. 
For every inverted file, an extra buffer is required and 
pointers have to be kept for the last record processed in 
every relation. This design uses the second approach, 
Q-enerality of the System 

The algorithm have been designed in a. most general fa- 
shion to suit any personnel data base. To achieve maximum 
efficiency for this application. Certain data structures 
have limited size and width. For example, condition tables 
has a variable field width of upto 8 bytes, i.e., fields of 
lengths upto 8 bytes can be used for search criteria. These 
sizes can be varied easily to suit any other data base appli- 
cations, The dialogue between the user and the comx>uter ma.y 
have to be varied slightly. 

Time Availability 

Time availa.ble for generation of this system has been 
limited by the M.Tech, program length. Many more features 
can be a,dded to the existing facilities. Some suggestions 
are made in the last chapter. 



3. ORGMIZATIOH OF RSLi.TIOFS MF 
LIEIC TORIES 

This chapter deals with the organization of data and 
the data structures that help to locate the physical address 
of the desired information. 
layout of Relations 

A relation consists of a set of similar records. A 
record consists of two or more fields vdiich are interrela- 
ted. These fields are placed adjacent to each other in a 
record. Records are placed adjacent to each other in memory " 


tabular representation of a 

re lati on 

i B 

shown in Figure 

Field 

F j e Id- 

Field 



A 


C 



GAIT. 

123 

10 


RECORD 1 

IT. 

122 

6 


RECORD 2 

MAJ. 

124 

7 


RECORD 3 

In memory the 

representation 't’ill 

be 


RECORD 1 

RECORD 2 

MAJ. 

124 7 


Figuxe 3-1. Xfayout of a Relation^ 


T\S.z 

Each of these refaction .las a particular field as primar^r 
key for identifying records. Some relations use more thar'. or." 
keys especially inverted fill "s, A primary key is used to 

18 
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EBLATIOrrS DIKE C TORY 


Kela- Kela- Poin- length Pointer JMo, oi Toxai 

tion tion ter of PD to Index entries No, 

Name call to list in memory in INDBF of 

FDIIST records 

in 


Na- EBINM EBLID PTEPDL NOPID jyyilNZ NIND TO ESC 

me 


Si- 6 2 1 1 2 1 2 

ze 


Exam-OEPS 01 40,000 4 60,000 20 6,000 

pie 



Current 

Record 

No. 

P rimary 

key- 

field 

Format 
of pri- 
mary 
key 

Secondary 

key 

field 

Format 

Name ORCNO 

KB YEP 

FMKRP 

KBYB.S 

FNKRS 

SIZE 2 

2 

2 

2 

2 

Example 20 4 

07 

3 

05 

8 
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.0 locate a group of records and a secondarykey used to 
locate a particular record out of that group. A relation 
of this type in this data base is EELATIOH ABM which uses the 
field OORTS to identify all officers belonging to a particular 
corps of service and then uses the officers personnel number 
to select a unique record. 

Relation Lirectory 

The logical organization of relations is cd®fih©fi-byi'-' t - 
a data structure named Relations Directory . Its layout is 
given in the table listed on the opposite page. This direc- 
to3ry gives all the particulars needed for processing. Its 
components are described below: 

1. RBCNM gives the relation name. It ma,y consist of upto 

6 characters. 

2. EBIATIOl'T CODE Bach relation is given a code number. In 
RSHIL 

our case it happens to be the serial nximber in the 
directory, 

3. rOIRTBR TO LIST OB BIBLDS It gives the address of the 
TTRBDC 

list of fields which form this relation, 

4. LEBGTH OB BIBLB LIST It gives the number of fields in 
NOBD 

that relation, 

5. AWINX It gives the local ion of the relations index 

table in memory. This INDEX table is a physical 
layout of the rela':ion. 
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6. NINB It gives the number of entries in the primary 
index table. It daows the number of disc 
cylinder being used by that relation. 

7o TOTRBC Gives the total number of records. 

8. GRCNO Gives the current record number. 

9. EE YET Gives the primary key of that relation. 

10, EMKRT Gives the length of the primary key. 

11, EEYRS Gives the secondary key. 

12, EMERS Gives the length of the secondary key. 

Pie Id I>i rectory 

This directory is maintained to store the information 
about the fields used by the system. The layout of this 
directory is given below. 


Field Code 


Address of 

Relations N am e length 
list 


Field List 


This list is maintained to co-relate relations fields. 
It has the following foimat 


Field Identi- FORMAT FDIST 
fication No. 

This field list struct-ure is used by the query inter- 
pretation part to fill up ol'her data structures which are 
necessary for processing thf query. Its description is 
as follows. 
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Pie Id Director 


Pield 

Code 


Address of 

relations Name 

list 


Length 


Field list 



FD ID 

FOEMAT 

F Dist 

FD 

ID 

Belati on 
ID 

Length Type 

Distance from 
"beginning of 


2 Bytes 2 Bytes 


1 Byte 


Figure 3-3 



PL' ID 
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It is a t®® Lyte field. First byte gives the Relation 
Number and the second byte ^ives the field number. 

POMAT 

It is two byte field. First byte gives the length of 
the field and the second byte gives the type of field whether 
alphanumeric or numeric. 

PDIST 

It gives the distance in bytes of this field from the 
beginning of the record. 

The routines take the required information from these 
tables and construct other data structures for their own use 
in SEEK, SBAHOH and PROCESS, These will be described in the 
following chapters. 



4. MAIF SCHEME MD DATA STRUCTURES 


Ob.iectiyes 

The objectives of the personnel data base retrieval 
system may be of the following t 3 rpes. 

(a) Eind out some or all details of a particular 
officer, 

(b) Find out some or all details of a set of 
officers who have the attributes as speci- 
fied by the user. 

The first type is termed as SIUG-IE QUERY . The second 
type is teimed as GROUT QUERY . Examples of each will be 
given later under q.uery translation. Both the types of 
q.ueries are quite common. 

Requirements for tacklinig the Problem 

In both the type of queries the job breaks down to 

(a) Tabulate what fields are the condition fields 
which have to be matched for some values. Also 
tabulate information about their location. This 

is tabulated in TBDROC . 

(b) Tabulate what fields are to be given as output. 
These are tabulated in TBOTPT . 

(c) Tabulate the conditions, their values and fields 
which have to be matched. COED TABLE . 

(d) SUBSCHEMA of the user in final output format. 
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Action Steps 

First of all the data structures have to he huilt up 
hy query translation. Once these data structures are built 
up, one relation is selected and the following steps taken 

[a] Seek the physical location of the sector 
desired, 

[b] Search the sector to locate likely record, 

[c] Scan the TBPROC for finding fields to be 
matched, 

[d] Compare these field values of the record 
against the conditional values, 

[e] If they agree, scan the TBOTPT for fields 
to be output, extract them f rom the record 
and make an output buffer, 

[f] Go and repeat Steps [a] to [e] for other 
relations mentioned in TBPROC, 

[g] Reject the first output at any time, any 
of the conditions do not match as CONB 
TABIE signifies logical MB of all condi- 
tions. 

[h] Once all the relations are over the final 
output buffer is reorganized as per sub- 
schema and put out on the printer. 

The data structures used are described below; 
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Lata Structures 

The following data structures are described 

(a) TBIROG Table for processing 

Table for output combined with TBPROG 

Table for conditions. 

Subschema of the user. 


(b) TBOTPT 

(c) GORD 

(d) SBCHMA 


TBPROG /TBOTPT 

This table stores fields which are to be processed 
or output along with necessary information about their 
length and layout of the relation. The information in 
the buffer will be of the following types, 

123 4 12 5 4 1 2 3 4 1,. 


Record 1 Record 2 Record 3 B.ec 4 

This particular relation has a record format consisting of 
4 fields of varying lengths 
FBI length 1^^ bytes 

Fi;2 length I 2 bytes 

FB3 length 1^ bytes 

FD4 length 1^ bytes 

A query may require only fields 1 and 4 to be processed 
and F2 to be output. Similary other relations will have 
other fields. The tabulation will be as follows: 
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TBIROC Rei, 

Fd. 

TBOTPT 

Rel. 

FD. 

R1 

FI 


R1 

F2 

R1 

F4 


R2 

F5 

R2 

F5 


R3 

FIO 

R5 

F6 




R3 

FIO 




extract these 

relations we 

must also 

have the 

details 


about the field lengths and locations of the fields within 
the relations. These two columns are added as FDIG-T (Field 
length) and FDIST (field distance from beginning of record) 
Since this information is required for both TBxROC and 
TBOTPT both these tables have been merged into one table 
with an extra column added which stores infonaation about 
the treatment of the field e.g,, whether this field has only 
to be oatput.. layout of the table is as given on the facing 
page. 

The treatment of the field taki^sr- the following shape. 

DiqiT AGTION 


Store 0 
Store 1 
Store 2 

The width of each 


Field has to be output only. 

Field has to be processed and OUTrUT. 
F.i^ld has to be processed only, 
entry is 5 bytes. The last entry will be 


zeroes in all columns to signify end of all fields. 
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TB n-oc/TBOTPT 


Relation 

Field 

FP length 

FD list 

Treatment 

^1 


h 

0 

2 


^2 

^2 

di 

0 

^1 

F 

4 

^4 

d2 

1 

^2 



^5 

1 

^2 

^6 

^6 


0 

Ej 

^8 

^8 

*^8 

0 

0 

0 

0 

0 

0 

1 Byte 

1 Byte 

1 Byfe 

1 Byte 

1 Byte 


Figure 4—1. Fable for Processing and Output 
Tre atment 

2 = Process only 
1 = Process and output 
0 = Outfiut only 



CONDITION TjffiDB 


FD 

ID 

PD Value condition 

Dength 2 Bytes 8 Bytes 

2 Bytes 

01 

0-12345 

Equal 

X 

XXX 

NE^ 

X 

XXX 

IE 

X 

XXX 

GE 

X 

XXX 

GT 

X 

XXX 

LT 

X 

XXX 

MY 

Equal 

NBQ 

N ot equal 


IE 

Less than or equal to 


GB 

Greater than or equal to 


GT 

Greater than 


IT 

Less than 


MY 

All values ok 



Figure 4-2 
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COHD T/3IiS 

The fields which have to he compared have their values 
and the type of comparison stored in this table. The struc- 
ture is shown in Table No 

Its entry length is 12 bytes. The first two bytes give 
the field identification. The next eight bytes are for the 
value and the last two bytes are for storing the type of 
comparison. 

During sssefc and process this table is used for matching 
values. The following type of comparisons are specifically 
allowed, 

(a) Greater than (GT) 

(b) Greater than or Equal (GB) 

(c) EQUAL 

(d) Not Equal (NB) 

(e) Less than (LT) 

(f) Less than or equal (IE) 

(g) MY 

This table is designed for a more naxi lengths of 
8 bytes. In this application names are excluded from 
comparison. The routine which scans this table is GOMT . 
SBGHMA 

This data structures holds the subschema given by the 
user. Its structure is as follows: 
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FD 

Tsrpe of 

Identity 

FIELD 

FI 

Numeric 

F3 

Alpha 

F4 

Nume ric 


4-1. Subschema Data 
Structui^ . 


This structure is also created at the time of query 
translation and is -used at the output time. The numeric 
fields will have to be converted into byie strings in a 
printable mode. The Alphanumeric information does not need 
conversion and can be directly given as output. The con- 
version of numeric fields from byte strings into binary 
n^un,ber equivalent is done to save storage space and save 
comparisons. 

These are the data structures used most often during 
processing. There are two other structures which do a mapping 
between logical address and physical address of records and 
sectors. These will be described in the chapter on the SEEK. 
®rom here we go onto the actual mechanism starting from the 
first step. The Query Translation . 



5. QI3BRY TRANSLATION 

FSER Leflnition 

fciotJ 

A Query has iw- parts: 

(a) set of conditions which have to he satisfied. 

(h) Set of fields which form the output in a par- 
ticular order. This lay out is also called 
the suhschema. 

Both these sets may he mutually exclusive i.e., have 
no fields in common, or may not he mutually exclusive. The 
user has to define hoth these sets. 

Query Translation 

Systems have heen developed 'v^ich facilita.te the user 
in defining the conditions and suhschaaa. They then extract 
proper information and develop^, data structures which are 
used for processing the information. Query translation then 
means filling up of the required data structures hy software 
routine s. 

Example: A typical example in this case will he as 

follows. 

Suhschema - output 

FDS S RANK, /^NiiMB, 44^1^ OB BIRTH 

of the officer with 

condition 

PERSONAL No, = 1000. 


32 
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This f Dims a single officer query. The G-roup Query may 
table the shape. 

S ubschema 

PDS. ?^ATB OF BIRTH 

of all officers with 

conditions 

FI’ fi=- Personal No, less than IC-2000. 

FI^ Parent Arm, equals ^ ARMOUR. 

This is a group query, 

lifference between a Group Query and a Single Query 

L single officer will have only one condition listed, 
his personall number. It may have any number of fields in 
the subschema. 

A group query will have more than one conditions listed. 
The personal number is always assumed as a condition as it 
forms the necessary link between different relations, 
lialogue Between the User and the System 

An interactive system "which permits the user to have a 
running dialogue while forming the query is very desirable. 
In the system designed here the user is in full conversation 
with the system, till his query is fully translated. All 
the fields in subschema and the conditions are displayed 
before him on the keyboard. 

Choice of Input Media 

This system enables the user to define his query either 
through the keyboard or the card reader. He is asked to 
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exercisu his choice of input device. 

Security 

A code check is incorporated to authenticate the user. 
The user has to declare the code prevalent at that time. The 
DBA can change this code at his will and unauthorised user 
is debarred. 

Description of the System 

Function : The system is called A2rR0/.GH. Its basic 

function is to obtain the subschona and the set of condi- 
tions required for seek and process routines. 

Data Structures Used : These are 

(a) GOHD TAB IB 

(b) TBPROG/TBOTPT 

(c) SBSCHMA 

(d) FD. DISECTORTFDilST. 

The GOND TABI2B will list the conditions ^ecified, the 
TBPROG/TBOTPT will list the fields to be processed/output. 
SBQHMA will hold the subschema, and FD DIREGTOETis used to 
obtain vario-us informations about the fields specified. 

These structure s lhave already been defined. 

Mechanism ; In the first part the system starts a 
dialogue with the user to establish his bonafide authority 
to use the system by asking him the code. Failure to supply 
this code rings a bell continuously. Other security measures 
can be suitably linked. Then the system asks him whether he 
wants re trie val/upd ate /building of data base. On being given 
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the correct answer (letter R) retrieval is allowed to begin. 
TBPRQO 

The second part begins with establishing the type of 
query, whether SBT&IiB or GROUT. This w ill decide the 
processing. It also gives him a choice of input device, 
card reader/keyboard. The user is then asked to list the 
fields which will .have to be processed or output with that 
specification. With his specification the data structure 
TBPROC is built up. It is then printed out as a table on 
the keyboard to enable the user to verify. 

CONP. TAB IB 

The third part asks for the conditions for processing. 

A set of fields with values to be matched is obtained from 
the user. Distinction is made between a SIRGIJB QUERY and 
GROUP QUERY. The numeric fields are converted from the key- 
board by.te string into the binary foim by subroutine BRCOUB. 
The condition/inequalities are put into COND table by sub- 
routine CO UP IT and the COUP table is completed for use. 
SUBSCHEMA 

The fourth part obtains the user subschema and builds 
SBGHCMA data structure to be stored and used for the final 
output. It is also printed out at the keyboard. After 
build up of these structures, the routine APPRO /.GH passes 
on to SEEK routines for further processing of queries. It 
also signals the end of user interaction. 



Subroutines Used 


This routine maizes use ot the foilowing subroutine 

(a) SCM 

(b) NO¥a 

(c) COHDIT 

(d) B FOODS 

Output 

(a) TBPROC 
(D) COFDTifflIE 
(c) SBCHMA, 



6. ACCESS MBCHMISM 


This chapter deals "with the SEEK routines and data 
structures used by them to physically locate the sector 
which contains the desired information and bring it into 
the memory for processing. It has to find the track num- 
ber, the surface number and the sector number of the disc 
Sequence 

The sequence of success is - 

(a) select a relation from the query 

(b) scan the relation directory for the address 

of index tables, keylengths by routine PmKSY. 

(c) scan the primary index table to obtain the 
track/cy Under number by routine TREES. 

(d) Bring the secondary index table i.e., the 
sector map of the track from the disc to 
memory. 

(e) scan this table to obtain the surface and 
sector number by FECSBC. 

(f) bring the desired sector into memory by 
READ. 

(g) mark the index tables for future reference. 

The routines mentioned in the above paragraph i.e., 

ERBEBY, TREES, PNCSSC, READ, are assisted by two other 
routines. 



(i) COMI which scans the COITD table, 

(ii) FNEI2 forms a part of both TBEIS and FNCSRC. 

rhysical layout of Relations 

The relations are stored on the disk. Rach relation 
may have one or more tracks allotted to it. Every relation 
starts from afresh disk. The TEC disk has 20^- tracks 
(usable) each having 10 surfaces. Bach surface has ten 
sectors for every track, A sector can store 256 b 37 tes. On 
the surface 0 of every track the first few sectors are uti- 
lized for storing the layout table for that tra.ck. The 
method of seeking a sector is described below. 

5 hysical Manning 

Indexed sequential method is used for storing and loca- 
ting the records. Two tables are kept as ma,pping devices — 

(a) Irimary Index Table 

(b) Secondary Index Table 
Irimary Index Table 

This table locates the track number. T'^^ere is one such 
table for every rela.tion. The location of these tables are 
given in the relations directory. These labels are stored 
in main memeory. Its la.yout is given in the figure 6.1. 



Highest key 
in track 

Track Ho, 

length of 
secondary 
index table _ 

SIZE 

Variable 

1 byte 

2 bytes 

Example 

IC-QL01234 

67 

80 


Table 6> 

-1, Primary 

Index Table 
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This table is scaimed by subroutine THKIS. 

Secondary Index Table 

This table helps to locate the surface and sector number. 
There is one such table for every track. This table is lo6a- 
ted on surface 0 of every track. Its length names as per the 
key length. Its layout is as below: 


No. of Records 
in the Sector 

Highest Key 
No. 

Surf ace 
No. 

Sector 

No. 


2 

bytes 

Variable 

1 byte 

H 

CD 

length 

51 

7 

4568 

0 

0 

Example 

51 

• 



0 

• 

1 

• 


* 

• 

25 



• 

• 

2 

• 

5 



Table 6—2 

. Secondary Index Table. 



Since there are 100 sectors on every track, there will 
be a maximvim of 100 entries in a table. The length of the 
table may vary from 1 sector to 4 sectors of 0 surface* 

depending upon the key length and total niimber of entries, 
¥ith the help of these structures a sector is brought 
into memory. This sector then has to be examined reoord-by 
bedord in a seria,! fashion by process routines described /ajg;: 

The working of the SEEK routines is described in the 
following paragraph. 
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IMZ TABIBS 
Primary Index Table 



Highest Key 
in track 

Track Ho. 

Length of 
secondary 
index 

Size 

Variable 

1 Byte 

2 Byte 

Example 

IC-200 

50 

80 


Secondary Index Table 



Ho, of records 
in sector 

Highest key 
^jLn sector _ .. 

Surface 

Sector 

Length 

2 Bytes 

Variable 

1 Byte 

1 Byte 

Example 

51 

0 

0 

0 


51 

• 

0 

• 

0 

•> 

0 

« 


• 

• 

25 

• 

• 

IC-300 

• 

# 

2 

« 

• 

5 


Figure 6-1 
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Subroutine FHBICRY 

Object : To locate primary key, primary key length., memory 
location of primary index table. 

Da.ta Structure used ; Relations Directory 
Outnut : IRKBY, I'KYLT, RLOC , SBEEY, SEYLT, MMR.' 

External symbols ; ROFST, KBYRT, KEYRS, PMRT, MKRS, iMIRX, 

FIRD, TEMD, MQ, ZERO, MSSGl. 

Working ; 

The relation directory is organized columnwise. The 
relation number is taken as the offset from the beginning 
of columns and the proper -value stored in output variables, 
PRKBY contains primary key field identity 
I’KYLT contains primary key length 

SRKBY contains secondary key field 
SKYIT contains secondary key length 
RLOC contains location of the primary index table. 
Subroutine TBKDS 

Object; To find out the cylinder address and load it into 
the disk control word. 

Data Structure Used ; Primary index table and CORD table. 
Output ; 

TKDR Track address word 
lEl’TR Primary index pointer 

TOTBRT Total number of records in the secondary 
index table. 
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gxtemal Symbols Used ; CPLO?, TKYLT, MI, lEKBY, RIOG, 

rXITR, PRDIX, TKDR, MBSGZ. 

'""‘•It - i'^g" gi-ven on- the facing page. 

Working; This subroutine puts the length of primary index 
table in variable G31MI and calls subroutine RHblX to scan 
the table for the highest key entry which matches the key 
given in condition lable. Then it reads the track address 
from the table qnd puts it into variable TKDR. It also puts 
the length of secondary index table for that track in TOTSRT. 
Seeking the STxrface and Sector 
Subroutine MCSSG 

This subroutine finds out the surface and sector number 
in which the information is lying. 

Data Structure Used 

Sebondary Index Table. 

Organization 

On ©very track, the surface 0 contains the index table. 
Since a track compa*l©4ngf 100 sectors, there will be 100 
entries in the index. If all the sectors are not used, the 
end of index table will be unaltered by placing a special 
word in the REBG (No. of Records) field of the Index iable 
Working 

1. Rirst put the length of entry into X, 

2. Read the surface 0, Sector 1, into Buffer BURF. 

3. Get the Bo, if Records in the index sectors from 
the first word of the BUFffiJU. 
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4. Set pointer SSX'TR to point at BTIFP+2. 

5. Test v^ether this hsite is zero. If it is zero, add 
the displacement x to it and g-o to next entry. 

6. If it is not zero, then SXPTR will now have address 
of the first data entry, 

7. Calculate various variables from this location as 
reference , 

At the end of this part of subroutine the following 
variables will have proper values, 

(a) SXTTR 

(b) mmc 

(c) CTR3 

(d) NISBC 

(e) HRBC (No. of records in that sectoi 
Now go to the other part i.e. , to FINDIX. This subroutine 
searches for the proper key field value. The exit from the 
subroutine can be either of the two, 

(a) Success*. the information has been found, I’ut SFI)([K=0 

(b) Failure-.the information has not been found. lut 
SFDOI =1, 

SFIOI = 1 Search Unsuccessful 

If the search is unsuccessful, the following action is 


taken 



(a) Increment sector counter. Compare its value with 
the HISBC (No, of sectors used for Index lalle.) 

(h) If the sectoj?" counter is NISEC, there is some 
error the information has not been found in the 
index. Write a message to that effect and stop. 

(c) Sector coimter = NISEC, This is the last sector 
put liESSBC (No. of records in the last index 
sector) in NESC increment the sector No. in 
surface sector word (SSOiR) for disk controller 
and read the next sector. 

(d) Sector Counter^ NISSC. The sector number is 
SSTIR and go to rea,d the next sector. 

SF10r=0 SE/UGHPROM ZINISBX SUCCESSFUL 

Take the following action: 

(a) Transfer the contents of sector and surface 
address in the SSUR for disc control. 

(b) Transfer pointer to number of records in this 
sector to SNCT. This will now store the location 
of the wanted record entry in the index table, 

Ifo. of Sur. sector 

Secondly 

Index Table — ~ — "" — 

Index 

__ Entries 


X - 


SNTT --- y 
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(c) Store the ciirrent surface and sector address 


in SAYSSC* 

(d) Clear all variables not req.uired. 

(c) Return from the subroutine. 

At the end of the subroutine, the surface and sector 
address is stored in the SSUR and also SAYBSBC. All other 
variables retain the values already mentioned except for 
CTR3 and and sector counter, 

SEEK Mechanism Finish 

Once the seek mechanism has gone throu^ subroutines 
TEELS and ENGSBO, the track address and the sector surface 
addresses are put into the disc controller and the system 
is ready to read the correcter* sector for the required 
information. Control passes to main routine. 


SUBROUTINE COMP- 

of 

Object : In the seek phase_^etrieval, this subroutine is 

used by EINBBX subroutine. It scans condition table for 
the key field value to be compared with the value in the 
index (either primary lable or secondary lable) tables, to 
loca.te the correct track, surface and sector number. 


LATA structure used 
1. OOHD- TABLE. 

Calling Instruction 

1. JMS , R5, COM! 

ARO 1 lord containing primary key fied (rEEBy) 

ARO 2 Word containing primary key length (rKYIT) 

iHG 4 ^ 3 ' lointer to location of first byte of field 
jFalue to be compared. 





Symlsolb Used ; CRT2, JHBQTRf CODE, VALCOM^ ECOND, PDLGTH. 
VALIOC, AKY, MATCH, 

OT^tput ; MATCH = 1, Moans comparisor success 

MATCH = 0, means comoar ' so’*; upcaocessful 
Wor king : Ini t igX n ze ; 

This vsuhroutine makes use of Ecglote.- !?■ and 4= I'"- also 

initializes counter 01R2 which keeps a track of hyues compar'o 
Locating the EDID in COED Table 

LI; The suhroutine puts the ahsolu'cc- address of CDLTD iu’;') 
R3. It transfer the 1st argioment i.e,, the ED IIEITTITY t.o 
CODE, 

12; I !7 then checks whether there ai'O eny conditiono aol 
up in condition table by comparing contents of EDID in COITD 
table with zero. If it is zero, ioS,, there is no condition 
set, the subroutine branches to sngnal success. Puts MATCHvrj 
and goes out, 

13; If the first entry is not zero, ir compares contents 
of code with the EDID in card table. If it matches the 
subroutine branches to compare that ED value, 

14; If it does not match, then the length of the cossd 
table entry is added to the R3 to point at the next EDID 
entry and branches to 13, It also keeps a count of the 
number of times this search takes place. If it exceeds the . 
capacity of c^ih<t table without finding that particular ED, : 
it signals an error, ED cede not found and stops. It will 
signal this condition also if it encounters a zero in the 
EDID field of COID table. That signifies end of condition 


tables 
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FD GODE IHiFTIFISD BLOCK MAT 
Setting of Symbols 

Once the field code has been identified, the algorithm 
has to compare the FD value transferred from the calling 
routine with the FD value in condition table under the 
condition mentioned in the OOFD table. It starts trans- 
ferring remaining arguments i.e. , the length of the primary 
key with FDLGTM and loc. of the FD VALUB to be processed in 
VALIOC. It stores the starting point of COFD table FD value 
in VAICOM. It sets the location of ISEQUAIITY in FGOND, R3 
and R4 are set to point at the beginning of values to be 
compared in the condition table data buffer respectively. 

Check Whether SEEK or PROGESSIFG Phase Block EALl 

If the call has come from the processing phase, the 
condition which has to be tested now will be listed in FCOFD, 
i.e., G-T or LI, LIB, IFrQ. etc. On the other hand if the call 
has come from SEEK Phase then the only cordition which may 
be checked is whether the FD value tested in the IHIEX table 
is GTE to the value in the COED table. Since the values listed 
in the Index tables are the highest key values in that track 
or the sector, i.e., primary index table. This is sufficient 
for a single type of query where all conditions will be put 
to BQUiJi, 
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PF a group query, the condition may he IE. In that case 
we must start processing from Track i. Similarly if the 
inequality is G-T we should test for greater than, not greeter 
than or equal to. 

This logic is done hy a group of instructions which first 
check /JET. M.J is an indicator for SBBE operation if it is 
set 


PI; If it is not 1, then go to the condition tested in the 
GOND table. 

12; If it is 1, then check condition table for BQUAl. 

If it is EQUAL go to GTE part. 

P5; If check condition is not EQUAL then go to the condi- 
tion listed in the GOFD table. 

Value Gomn arisen 

Once the field has been identified, pointer set to point 
to field value location^ the control jumjis to the condition 
testing blocks as per the condition listed in the GOUL table 
these can be: 


1, BQUAL 

2. LT 
5. GT 

4. SEE 

5. lifE 

6. FEQ 

7. AMY 


Less than 
Greater than 

Grea-ter than or equal to 
Less than or equal to 
Not equal 
iuiy condition. 


The algorithm compares the field values byte by byte, the 
comparison is in the shape of (R4-B.3), i.e,, value to be 
processed - value to be checked in GOFD table. There is 
counter GTR2 to keep a coimt of byfes compared. Any time a 
condition is satisfied, the program jumps to either FAIL 
or SUGGBSS. 
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Success /Failure 

After every lyte is compared, the counter is incremented, 
when it becomes equal to FDIG-TM (Field length given earlier), 
juiip-s- to fail or success. This happens when all the 
earlier bytes have been equal and the last byte is the decid- 
ing factor. 

SUGGESSt If the comparison has been successful MATGH 
is mp.de equal to 1, A messs-gef is given to 
console and subroutine returns, 

FAIi: If the comparison fails MnTGH = 0. Subroutine 

passes a message and returns. In either ca,se 
Register R3, R4 are restored. 

TiOgic of Gomnarison 

EQUAL (l) Gompare one byfe of both R4, R3o If they are 
not equal, go to FAIL. If they are equa.l 
GO TO FBQll. 

(2) FEQLI Bloch : increments counter, compares 
it with FDLGTN, if it is less than FBIGTM, 
increment R3 and R4 and go back to Step 1. 

(3) If counter is S-TS equal to I02CGTM, that means, 
it he.s finished comparing all the bjrfees since 
it has come from equal it is a successful 
comparison, i.e., OTR ^ FLIGTM - GO TO SUCCESS, 



5a 


IT (l) Compare one byte of R4, R3. 

(2) If R4 ^ R3, i.e., sign bit is set, branch to 
success . 

(3) If R4 = R3 i.e., zero bit is set, branch to 
REQL. 

(4) If R4 R3 sign bit is 0. Oo to RAIL. 

REQL block does the reverse of RBQLl. If counter is equal 
to FDKtTM, that means the two quantities are equal and LT 
is not satisfied, GO TD PAIL. 

Going to PBQL and FBQLl means the earlier comparison was 
equal. If it is the last byfe, then the whole of the values 
were equal. 

GT (l) Compare one byte, 

(2) If equal go to FBQL 

(3) If R4 R3 branch to success 

(4) If R4 V branch to FAIL. 

GTE (1) Compare one byte of R4 and R3. 

(2) If R4 'a R3 success 

(3) If R4 = R5 branch to FEQLl, 

(4) If R4 - Go to FAIL. 

LIE (l) Compare one b3rte of R4 with R3 

(2) If R4 J R3 - success 

(3) If R4 = R3 - FBQLl 

(4) If R4 / R3 fail. 

WBQ (l) Compare one byte 

(2) If they are R4 ^ R3 (zero is clear) Branch to 
Success, 
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(3) If tiiey are equal R4 = E.3, branch to FBQl. 

MY Bm to Success. 

SUBROUMB FIDIS 

Ob ject; This subroutine scans the prima,ry index table and 
the secondary index tables when called for by subroutines 
TRKDS and PRCSBC, and gives out the location of the required 
KET EE value in the index table. 

Pat a Structures Used 

( 1) Primary index table 

(2) Secondary Index table 

(3) GONE table. 

S ubroutines used ; COMP. 

Symbols Used ; OTRl, CTR3, LOG, MBSG9, PEKBY, PKYLT, MATCH, 

CPlOr, NEBC, SPLOP, MESG16, MBSGIO, X, AKY-FIAG- 

Gallinf^ Instruction : JMS R3, PREIX 

/iRGl (word loc) 


Initialization Transfer ^RG: Block A1 


It increments counter GTR3 which keeps a co\int of Records 


processed in the secondary index table in subroutine PRCSBC. 
It also transfer the pointer to the PE value in LOC, In 
addition it sets a fla,g iiEY = 1 to indica.ts that it is a SEEK 
operation (used in COMP subroutine). It then checks whether 
there is any data in LOG. If it is zero that signifies the 


end of the Index table and is an error jC|:) 


rint 


centr al I isHkm 

~ A 58871 

Ace. No. £% .. 


a message. 
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Scan of Table 

( 1) The pointer LOG points ito the location of 1st byte 
of the PD value to be compered. The PIDIS routine calls 
subroutine COMP to compare the values. The result is either 
MATCH = 1 or MATCH = 0, 

(2) If MATCH = 1, then the search is over and bra,nch to 
success block SURSBC and return. The value LOG will contain 
the proper location of entry desired, 

(5) If MilTCH = 0, then we have to scan the next line of 
index table. Advance location by the length of the entry 
of the index table (X). Block A2, 

Locdi- Loc+x - 
loc ^2=Locl+x 

(4) Jifter it advances the pointer, the algorithm goes 
back to step Al, to increment counters and checking for a 
zero in the first byte of the PD value, 

PIHDIX in seconda.ry table search 

If the table being tra.versed is secondary table, then 
there are some additional checks to be made. As such after 
return from comparison with a Match value =0, It establishes 
whether it is secondary index lable or not by checking the 
CPLOI flag. This flag CPLOI is reset by the TEKDS subroutine.' 
It is set to 1 by the PFGSj^C routine. In the end of query 
this flag should be cleared. 


Loc 

1 ^ 
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Action for Secondary INDEX Table (Block SECY) 

Since ttie secondarj?’ table resides on tiie disc, only one 
sector is brought into the Memory h i^-t this time NRBO 

contains the nimaber of records in the sector. As the checking 
proceeds on the information, counter 1 GlRl keeps a track of 
records processed. If this counter becomes equal to number of 
records, i.e., IB CTRl = REBC that mean all the records in the 
sector have been processed -vrith no match found. It then sets 
a flop SFLOr to 1 to signify failure as far as this sector is 
concerned and returns to the subroutine BrCSBC, which will 
bring in a new sector of the index table and recommence search. 
Suc cess 

Once the desired en'cry has been located, the subroutine 
prints an exit FNDIX message and returns. 

F-rrors 

If no match is found it prints a message UJRBX TABIB OYRR 


and stops. 



7. PIiOCBSSIFO SnmiB OFFICER QUERY 


The search for information can he of the following tsrpes: 

(a) search for particnlars of one officer 
(h) search for a block of officers 
(c) search am entire file. 

The factors involved in all these types of searches are dis- 
cussed in this and the following chapters. 

Individual Officer Search 

In this type of search, one individual key like the per- 
sonal number of an officer is given and one or more other 
fields information is desired, in example - 
OUTPUT (a) Date of birth 

(b) Year of commission 

(c) Qualifications 

(d) Next to kin 

for Personal No. lC-2000, Capt. S. SINGH. 

The fields on which information is desired may be from 
one relation or may span more than one relation. The personal 
number being the key for all relations, except for the inverted 
files, a.ll such relations can be scanned. The method of 
search employed will be the standard procedure for search 
based on primary key. This method is outlined below; 

Method of Search and Proces s 
1. SEEK 

(a) Select the first relation 

(b) Scan the primary index table and the secondary 
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index tables to locate the physical sector 
on the disk. 

(c) Bring the sector to the main memory buffer. 

2 . Process 

(a) Search this buffer on the primary key and locate 
the particular record. 

(b) Extract the fields desired to be put out and put 
them in output buffer. 

(c) Check whether all fields required have been obtained, 
if yes, go to (e). If not go to (d). 

(d) Obtain the next relation and go to back to 1(b) 

(e) Arrange the output in the subschema format (Bata 
sub model) and print. 

(f) Go to end Routine. 

In this type of processing sectors of the current relation 
being processed can overlay the buffer of the previous relation. 
The change over of relations require no reassignment of pointer, 
buffer. The routines used in this type of query processing 
are : 

(a) SBEE 

(i) FNDKBY 

(ii) EITCSEC 

(iii) EIRDIX 

(iv) COMP 

(v) TREES 

(b) IROOBSS 

(i) IROC 
(ii) OTPT. 
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SEEK 

The method of finding out the physical sector/hlock 
and how to bring it into memory has been explained earlier. 
Once the infonaation is in buffer it has to be processed as 
detailed below, 

SSi'JlCHIE-Buffer 

The location of the record in the buffer has to be done 
by a sequential search. Provision also has to be made for 
sliipping a blank or deleted record, and errors signp-ls to be 
provided if identification of record is not obtained. Such 
steps are out lined below, 

SI; Rea,d a record 

S2; Check primary key field 

S3; If it is a blank or key value does not match the 
key given go to S4« Else go to S5. 

S4i Is it end of sector or end of file'; If yes signal 
error else advance pointer and go to SI. 

S5; Check fields required by the OTPT table and put 
them in the buffer, 

§6; Arrange fields as per subschema. 

Information in Tables 
CORE 

In this type of retrieval, there will be only entry in 
the COID table, that of personal number, EQUAL Value 


01 


VALUE 


EQUAL 





This value will he checked every tiae a are cord has to- he 
checked. 

Irocess and OTPT Tables 

In a general case the TBIROC has to he scanned to check 
all the fields which ha,ve to he conx^ared in every relation. 

L pointer is positioned at the head of buffer. Pield are 
selected from the TBIROC and successively compared with va.lues 
in buffer records are processed till a record is found which 
matches all the field conditions of one relation. Then IROC 
takes on the next relation and so on. 

In the single query, the above method is not referred, to. 
The only field to be compared is Irimary key field. If we 
were to follow the general method for every relation to be 
processed the personal number will have a corresponding entry 
in TBPROC. The structure of the TBIROC /TBTPT will be as in 
the table given below: 

TBIROC 

~RBL. RO. FDID RD ISRGTH RBIST ACTIOR 

R1 01 8 0 1 

R1 03 4 8 0 

R2 01 8 0 SO 

X- R2 05 4 12 0 

R3 01 8 0 0 


R3 


07 


10 


12 


0 
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We see here that FC 01 which is the key field for all 
relations comes in for comparison in every relation. Also 
care will have to he taken to see tha.t it is not repeated 
in the OTIT of every relation, This complication is avyidar- 
hie for single query and the modification is described below. 
Modlficgution 

We know that the primary key field is the first field of 
every relation. The distance from the beginning of every 
record FDIST = 0, Its field identity known as well as xts 
field length. 

Once we have this information in memory, we put FDIST=0, 
bjfpass the TBPROC scan and start comparing the value in the 
buffer to with that given in the COND table, 'When a match is 
struck pass on to OTIT routines. 

For this query, the TBPEOL/TBOTrT may not contain the 
key field entry at all unless this key is also desired as 
the output field. 

Stonning the Algorithm 

This algorithm deals with only one particular record 
relation. Once this record has been located, all fields 
output, the system should stop and give a message job over. 
If the informa.tion is not found in that sector, then there 
is some error and an error message should come. Thus the 
algorithm should stop in the following states. 

(a) JOBOVBR after OTPT routines over. 



59 


PROCESSING SIRGIS QUERY 




layout TBPROC 


EEL 

ID 

FD 

ID 

FD 

LGT 

FD 

DIST 

Action 


R4 

1 

8 

0 

1 


R4 

5 

2 

12 

0 


R4 

8 

4 

14 

0 


R5 

10 

4 

8 

0 


R5 

0 

0 

0 

0 


De tai Is 






FD 

Length 



FD 

Length 

RBI 

LGT 


EEL 


'' ID6 

4 01 

8 


5 

01 

8 

03 

4 



10 

4 

05 

2 



15 

2 

08 

4 






Figure 7-1 
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2. Error in Sector 

If it is first relation and the officers record is not 
found, there is error in SEEK. Give error message. 

Once the SEEK is over, the only checks to he made while 
processing are: 

(a) Is it a blank record. If yes go to next record. 

(h) Is it end of sector. 

(c) Is it end of file. 

These checks have to he made every time a record is pro- 
cessed. In case it i s case (h) or (c) and it is not relation 
1, the output should he filled with blanks. In case of 
Rel. 1, signal error. 

METHOD OP IROCBSSIHG 
^ 

The method of processing is illustrated by an example. 
Take a case in which infomation is to he obtained from two 
relations Rel 4 and RB31 5. The layout of these relations and 
the structure of TBIROC is given on the facing page. The 
first relation to he processed is RBI 4. 

SEEK 

The seek mechanism puts a sector of RBI! 4 in the memory 
buffer BUPF. .vwV W- The seek mechanism 

also gives the following information 

1. EEBG contains no, of records in that sector 

2. KSGIG^T contains records length 

5. REKID contains relation ID, 
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2RQG 

The processing algorithm first transfers this information 
to the variables mentioned (Block T iJtG). 

It then checks for type of query by TST SIRG-IiB. In 
SBTGIB case i.e., SINGIE = 1, FDIST = 0, FDLG-T = 8. 

This inf oiiiie.tion is put into two variables, KPDIG-T, KIT’D and 
transferred c .^-ais-'O-ito- variables FDIOC, PDLG-T. Row the 
portion of processing TBIROC is bypassed. A pointer BUPPTR 
is positioned at the start of BUFFER in the beginning and it 
keeps an incrementing by RBCIG-T to keep pointing at the head 
of successive records. Another pointer TEMI is utilized to 
point to the location of the field, which is being processed. 
In single query TEMI' and BUFPTR will coincide at the beginning 
of every record. 

liter the checks have been cleared, the identification 
field has to be compared. Block IDBRTF calls forth GOMI. 

If the output MATGH = 1, then the process passes on to OTDT 
to output desired fields. 

If the field does not match, the control branches off 
to NXREG which checks for record count and increments record 
counter. It adds record length to BUFFTR. Then it branches 
back to GTFD to start processing next record. 
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Ir ansitlon from One Relation to Another 

In a single query the transition is ea sy. There is no 
field to be passed on to next relation. Just select the next 
relation from TBIROC and start overlaying new infonaetion 
on the buffer. 

Processing: Bnd Conditions 

It may happen that a particular rela.tion infonaation ma,y 
not exist for that officer. Por example, IC-20000, Capt. 

I' . KIM/Ji may not be a graduate . As such his name will not 
figure in the relation QUAI, In this case, the seek mechanism 
will put a sector which should contain the information if 
it exists. An end of sector will be encountered without 
matching the key. The processing should not stop here but 
should go to next relation in TBIROO/TBOTIT and should fill 
blanks in this officer's qualification field. In the last 
sector Bnd of Pile may similarly occur. The action will be 
same in this case. Only in first relation should the error 
be signalled in case of End Sector or Bnd Pile Condition, 

Imp ortant 

The first relation in the query diould be one containing 


all officers data. 





























8. aRODP QUSiaiBS 


There may be two types of group queries: 

(a) Queries about a group in which a subset of the 
complete relation is to be searched. 

(b) Queries covering sin entire halation. 

Subset Search 

There will be some condition on the primary key by which 
a particular block of information will be checked. The re- 
trieval is in two phases - 

( 1) Seek the file portion which meets with the 
primary key condition. 

(2) Process the relation. Keep a check on the 
primary key value snd stop the job once the 
primary key value goes out of the range 
specified. 

Bxam-ple : Print out 

Rank 

Rame 

Unit 

of all officers belong to corps of engineers. 

In this case relation Ro, 1 will be CORPS and search will 

commence when key vaPue equals engineers and stop when the 

key value changes. 

Bxamnle 2 Print out 

Rank 

Name 

corps 

of all officers v hose persana.! number is less 

64 
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than IC— 10000. The joh gets over when the hey value he— 
comes IG-10,000. 

Full Relation Search 

This normally follows a search based not on prima,ry hey, 
seaxch starts from the 1st sector of the relation and goes 
on till EHL of file has been reached, 

Exam-pie 

Trint out the names of all officers whose state is 
MimilRASHTRA and whose date of birth is less than 01 January 
1940. 

Riff erentia.tion Between Queries 

The first level of different! alien comes from putting 
a variable SIIGIS. Row we use another variable GROUT. If 
GROUT = 1, it means the query is on primary hey and a subset 
of a relation has to be searched. This condition has to be 
tested only after SINGIiB has been tested. When both of them 
are zeroes it will mean a f-ull relation search. 
Characteristics of a Group BRQUIRY 

The special characteristics of group queries are listed 
in the succeeding paragraphs. 

1. ERL OF JOB 

In a single query the job is over, once all the fields 
of OTIT table have been covered. The system then returns 
to initial conditions. 

In a group inquiry, after the DTTT lable has been 
covered once, the system proceeds to next officers records. 
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It has to go hack to the first rels.tion end start processing 
from the point it last processed. Bnd of job will come when 

(a) A mismatch of primary key occurs or 

(b) It reaches BND OP FIDS in relation No. 1. 

These checks have to be made after every print out. 

2. of Pointers to be Kept 

Since the processing returns to the first relation after 
every successful record output, the pointer to the last record 
processed in Rela.tion No. 1 has to be kept. 

Also one pointer has to be maintained for every relation 
which is an inverted file or in which every record does not 
have a unique primary key. 

3. No. of Buffers Used 

In a single type query only one buffer is sxifficient as 
no return to any relation is required. In a group query one 
buffer is required for the first rela.tion in the TBIROC and 
one general buffer for other relations. In addition, one 
additional buffer will be required for each of the inverted fi 
relations, in which pointers have to be maintained. 

4. Transition from One Relation to Another 

In group query, the following information has to be kept 
a. live 

(a) Buffer for first relation 

(b) lointer in first relation to record last 
processed 

(c) Buffers and pointers to inverted file relations. 
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5* Action of Brror Messages Oome 

As in the case of SIEGIB QUERY if an end of file comes 
in the first relation, the job is over, iind end of file in 
the other relations means blanks have to be filled in those 
fields and proceed to next relation. 

Every time a changeover of relation is taking place the 
action as described above has to be tskien. In this ca,se since 
personal number is the prima^ry key of all relation except of 
Relation No. 1, the personal number of every officer can be 
put into KYFD and EFDLGTM. No change in COKD FIEIiD will be 
required and all relations ex;cept for Relation No. 1 will 
take their personal number keys from KYFI instead of COFD EIBIjI’. 
S equence of Processing Groun Queries 

Initiall ze ; Set SINGIE = 0, NREl = 0, set pointer to 
beginning of buffers. 

&2. Select the first relation. 

G3. Seek the beginning of a group required in first relation, 
such a particular record in all other relations. 

G4- Process the record against IBP ROC. 

G5. If found OK put personal number in KYED, Store the 
pointer in buffer in case of first relation. 

u 

G6. Rroceed to OTPUT routines. 

A. 

G7. Check whether all fields of this relation to be processed 
or over. 

G8. If yes, save buffer and pointers settings, go to 6 GIO 
else go to next G9. 

G9. Bring in next field relation. Go to G4. 
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G-o To Process First Relation 









GIO, 


Glieck whether all relations over| yes Go To 
else follow. 

Gll, If it is first relation, change huffey settling to BIIPF2 
change values in KYPl, KPDIGTM. Br^g in'new reiat^on 
and go to G4, If it is not first gelation nocdti^ge'in 
settings required simply overlay. 

G12, All relations over. Print OTPUT. Ghsck whether query 
is over. Ss If yes, GO TO G14, else G13^ 

GI 3 . Change Buffer settings to Btiff 1. Go to process Relation 
Fo. 1 (G4). 

G14o Go to End routine. 

Act ion at the end of Sector Routine PROP F 
7 ' ^it f rom Process 

¥hile processing a particular sector in a particular rela- 
tion the following situations may arise. 

(a) End of Sector. 

(h) End of Relation, 

In either case, there will he an exit from the PROG routine 
•'jith a failure indicated by SWITCH2 = 0. The exit will also 
set another flag SWITGH3. SIWTCBI=#=Of or end of sector and 
S¥ITGH3=1 for end of Relation. The action to be taken is as 
described below and is also indicated in the flow chart. 

E nd of Sector 

The end of sector action varies with the relation. It 
also depends upon whether it is a single query or a group query, 
(a) First Relation 

(i) If it is a single query end of sector means 
end of job, 

(ii) If it is a group query it means action to go 
to next sector. 
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(t) Relation not First 

Bnd of sector signifies filling up the fields of the 
relation with blanks. 

Incrementing Sector. Surface, track 

Ihe following logic applies in incrementation. 

1. Increment sector count. Check whether it exceeds 
10, If so go to increment surface count and reset 
sector count to 1, 

2. If the surface coxmt exceeds 9, then go to next 
track from seek subroutines and primary index table. 

3. If the track count exceeds number of tracks used as 
mentioned in Relation table mark END OR JOB. 

END OF RIIS 

If it occurs in first Relation then it means end of job. 

In any other relation it will mean filling up blank for that 
relation and go to output routines. 

Error 

Exit from Proc. on any other accovint means error condi- 
tion, Stop and give an error message. 

Conclusion of Processing 

Once the officers record has been processed and put in 
the output buffer, the routine FOTPT takes over and rearranges 
the output in the format of the subschema supplied by the 
user and control goes back to MAIN routine. 









9. OUTPUT ROUTIl® 


The processing routine, prepares a buffer for output 
in which the various fields are arranged in the order in 
which they appear in the table OTPT. This may not be the 
order in which the user requires the output. Thus another 
routine taies over which rearranges the order of the fields 
as per the requirement of the subschema. 

F ormat 

At the end of the process routine, the output buffer 
has the following shape. 


FD 

IDE UT ITT 

FD 

EEUGTH 

VALUE 

-wr~ 

RE 

^ 

IDE; UT ITT 


1 Byte 

1 Byte 

Variable 

1 

6 




Fig. 9-1. layout of buffer at the end of processing. 
The desired format will be as per subschema and will have 
the following shape. 


FD VALUE 1 blanks FD VALUE 2 


xxxx 


012 


Figure 9— la. Final output 
Routine Working 

Every time the OTPT routine prepares a line to be 


printed, it hands over to OUTPUT routine. The output 
routine makes use of the following data structures 
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(a) SBGHMA 

It picks one field at a time from SBGHMA and scans the 
buffer for this field. On finding this field it puts the 
field length into a counter and transfers that many bytes to 
a temporary storage area, 

G heck Tyne of Field 

It then reads the type of the field f rom SBGHMA, If 
it is numeric field, it has to be converted for printing. 

If it is alphanumeric it can be transferred straight. After 
converisrion, this value is stored in the output buffer. Then 
the desired number of blanks are put in the output buffer. 

This information is also to be stored in the SBCHMii. 

Pr inting 

Once the output buffer is ready and the end of SBGHMA 
has been reached a command is given to the printer to print 
the desired information from output buffer. The whole line 
is printed and control goes back to process routine. 

JO B OVER 

Once the job is over, a message should come to the 
console and the printer. The printer ships a few lines and 
prints out a line of dashes to mark the end of table. The 
console prints out JOB OYER and the system returns to original 
state ready to accept new commands. 



10. EBGOMMBIDATIONS 


Due to the frequent failure of the TDC-316 system es- 
pecially the input-output devices, it has not been possible 
to subject the system developed through rigorous '-te^ts. While 
working with the system, the following areas have shown need 
for improvement in design, 

1 • Query Translation 

(a) At present the user needs to know the field identi- 
fication for preparing fields. The subroutine operates on 
the numerical value of this field. It should be able to 
opera te on the names of the fields given. 

(b) There are three sets of cards to be f ed in for making 
data structures 

(i) TBPROC 

(ii) COND 

(iii) SUBSCHEMA 

It is possible to reduce the number of sets to only two * 
TBPROC and COiDD can be combined. It will also aid in avoid- 
ing errors during processing arising out of differences while 
creating these data structures. 

2. OUTPUT 

As yet the system is geared for ^^putting out ASCII 
coded informR,tion only. The final output routine POTPT can be su 
suitably modified with NOWR routine of DB routines to handle 
binary information to be output. 
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( o ) Data Structure Size 

The data structure sizes have been a-rbitrarily decided 
to meet normal operating conditions like 

1. GOND Table can handle 10 conditions 

2. Maz. '.field size for comparisons is 8 bytes 
so names cannot be a basis of search^ 

The sizes of the data structures can be modified to suit 
individual system requirement. 

(d) Inverted Files 

The system operates on one inverted fiflie only. To in- 
corporate more inverted fi3.es suitable modicatlons will 
have to be made in the MAIN routine. Also, ■ additional 
buffer of 256 bytes have to be reserved for each additional 


inverted file. 
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iPPBHUIX 1; Method of Using the System 


The information retrieval system occupies memory space 
from 60,000 to 72,000 (octal address). The routine approach 
starts at 72000. The system maices use of the following 
external routines: 

(a) SCiiN called by letter SG line feed. 

( b ) Read 

(c) SET. 

Calling Instructions and Dialogue 

The routines are placed in the system area of the disk 
and 8.re placed with EDM. The procedure is as follows: 

1. load EDM 

2. Start from 0173500, /in asterisk will be typed 

on the teletype. 

3 . Type ’SG’ line feed. i\n asterisk will again be typed. 

4. Type ’Zip' If. Approach will be loaded. 

5. Type ’ME’ If. Main will be loaded. 

6. Set address 7B000 from console and press start. 

It will start the dialogue. 

Dialogue 

The starting message will be 

GI7E ID EO. 

Fill in the ID Eo. for that day (at present 123) and press 
IF. If the number is incorrect, the teleprinter will type 
a message. 
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'UlTAUTHORIZBL USSR^ and start rinsing the hells. 

Start again from 72000. 

If the ID is correct, the following message will be 
typed: 

USER VERIFIED PROCEED - 
FOR UPDATE TYPE IE U 
FOR ESTRICVE TYPE IN R 
IF DBA TYPE IN D 

Press R LF then the system types out 

STARTING RETRIEVAL, INDICATE TYPE OF QUERY 
IF SINGLE OFFICER QUERY, PRESS S, ELSE G IF 

Here the system finds out the type of query from the user. 

If proceeds differently in both cases. In case of single 

query, the only entry in condition table will be his persona.1 

number. 

Action on Single Query 

If you press S LF the system will type out 

SINGLE QUERY, IF INPUT DEVICE HARD PRESS ’G’ IF. 

IF INPUT DEVICE EEY B PRESS FF IF. 

Depending upon the type of input device press G or E IF. 

The machine then types out 

TYPE IN LEVEL FDNAMB , FDID, JOB ON THE FD. 

Definition for FIELLS 

The user has to now give the list of fields which he 

wants to process or output the format of this informe.tion is 

02 ^ ^ 

Any 6 cha.racters. First character to be an 

alphabet. -nr 7 _ -wat 

FD No. 1st letter should be F e.g. , F7 or FO ^ 

Blank for 0, 9 for putting 1 in TBPROC, 99 for 
nutting 2. (O means output only, 1 process and 
output, 2 process only) 


Level 

fdn/fes 

FDID 

JOB 
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Put a blank between each entry and end with a (.) IP. 

e.g. , 

02 t NMB POl )!$ 9 . IP. 

The system prints out the message e.g., field defsnaition 
and asks for HEIT FD. Type in all the fields and finally 
end the field listing with (.) IP which will put zeroes 
in the last entry in the table for processing and output 
and print out 

AH, FIELDS OVER PRIHTIHG TABLE FOR PROCBSSIFG 
MTD OUTPUT. 

Theht the table is printed out. It consists of ten 

lineg' each of five entries. 

The columns are as follows; 

1st Relation No. 

2nd FD No. 

3rd Field length 

4th Distance of field from beginning of record 
5th Job to be done on this field. 

After it prints out the TBPROC, it prints a message 

TIPE IN PERSONAL NO. 

Fill in the personal number and press IF. The system 
registers this personal number and then gives message 
COND TABLE OFER GIVE SUBSCHEMA. 

It also asks for choice of INPUT DBYICB, keyboard or C&rd 
output. Now give the list of fields in the order in which 

the user desires them to be output, e.g., 

FI 

F5 

F6 

F4 
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The definition of the fields will be in the same pattern 
as described earlier. Every time a field has been entered, 
the bell rings for a new field. End the subschema with a 
(.) LF. The system then types 

SUBSCHEMA OVER 

JOB OYER 

PRESS CONTINUE TO START RETRIEVAL. 

Press continue to start retrieval of inf orme.tion, 

G-rout) Query 

When you press G in response to type of query it finds 
GROUP IN-lUIRY GIVE PD ON WHICH SB/UCE IS BASED. 

In response to this message type in the field specifications 
on which the search is based. It i s primarily meant to use 
for retrieval of inverted file Relation 1, which is based on 
PD 05. The system types out the details of field and asks 
for choice of INPUT device. Then the dialogue is same as 
for SIITGIE query till the printing of TBPROC is over. Then 
to build condition table it again asks for choice of INPUT 
device. Once the input device is mentioned it asks for 

GIVE CONDITION PD 

Specify the PD No. as done earlier. The system registers 
it and asks 

GET VALUE. APTBR VALUE GIVE ONE BUiNK IP 
Type in value and press IP, The value is registered and the 
system asks 


GIVE CONDITION. 
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Type in the condition for this field may be 

SQUAl 

MEQ 

&T 

GB 

IT 

IB 

ANY and press IF. 

The system registers this condition and goes back to ask 

GITS CONDITION FD. 

The user fills up all the condition entries and then as the 
last entry enters (.) IF. 

The condition table is over and now the system goes to 
make subschema. The dialogue is same as for single query. 
In case the user selects the card as input, all the condi- 
tion field entries are put on the card. See example below, 
CART' INPUT FOP THE SYSTEM 

There are three series of card inputs. These are in 
the order and format given below. 

For TBFROC 

02 t XYS i 9 / 99 /)^ ^ 

« 

0 Ti IF - (last card) 

For CONI Table 

02 ^ XYZ FN' >5 . YiYL COND 

% 

62 ABC F 2 . 100 DQTJAI 


0 . IF (last card) 
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For SUBSCHEMA 

Since these are only output cards 

02 ]!> FN . liF 

» 

0 . FF 

cards for all the groups can he kept on the card reader in 


one stack 



AppBFDiX 2, Programme Layout 


The programme is divided into the following parts 
with starting locations as shown; 


MAIN 

Location 

60,000 

SBBK Routines 

(a) PNLKSY 

62,000 

(b) END IE 

62, 400 

(c) TEEDS 

65,000 

(d) FNCSBC 

65,300 

Processing Routines 

(a) Proc, 

64,000 

(b) Proc F 

64, 600 

OUTPUT Routines 

(a) OTPU 

65,500 

(b) FOTPT 

66,200 

Query Translation 

(a) Approach 

72,000 

GBN ROUTIIffi) COMP 

61,332 

GBN. ViJlIABLBS 

67,300 


These routines have already been described in the various 
chapters. MAIU routine calls the other subroutines ti m. by 
for retrieval. 

In addition it makes use of external routines from DB. 
These are 


(a) SOiiN 

(b) GST 

(c) BB/J) 

(d) SIT. 

These routines are loaded from 20,000. After calling EDM, 
Do ad L5:.. 
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LISTING 

Tile listings size does not perait it to te attached 
to this thesis. Copies of listings are kept in the computer 
centre lihrary. 

Functions 

The main routine is the controlling routines. The 
SLBK routines locate the relevant sector of information on 
the disk and ]pu-t it in memory buffer. The processing 
■routines then process the information in the buffer. The 
output routines prepare output buffers as per the subschema 
given by the user and output it. 

The query translation elicits specifications from the 
user and prepares data structures, COIL TABLE! , Processing 
table and Subschema. 



ill’PBNDIX 3. Working with. TDC - 316 


This project was taken up on TDC— 316 especially to try 
out the TDC-316 system with an intensive usage. The project 
has been successful in this respect as it has subjected the 
TDC-316 to real heavy loading. The system at the Indian 
Institute of Technology, Kanpur has proved to be very un- 
reliable with a very heavy down time. The main points 
observed are listed below; 

1. CARD KBADBB. ; Break down in blower system, too 

frequent pick checks, resulting in 
heavy loss of input time. 

2. PRIFTEIR ; An old model printer which gave exten- 

sive trouble in paper feed mechanism 
for over a month and a half. 

3. DISK? : Ko protection of system programs possi- 

ble, Disk heads got damaged once. 

Disks scratch very early. 

4. KBIBOxlRD ; Off line OK. 01 IIIB possibly due to 

bad connections at C3PU gives very fre- 
quent troubles. Also the model is 
light duty model, should not be used 
more than 2 hours at a str^ch serious 
time taken 

5. PAPER T/iPB : By and large satisfactory, 

SYSTEM 

6. COISOIB ; Almost trouble free. Power supply gives 

trouble. 

7. CPU : Frequent troubles in disc controller. 

Hardware bootstrap and keyboard cards. 

8. MEMORY ; Very good. Except for failure in power 

supplies it has been trouble free. 
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Due to frequent failures of tiie j?B RIP HD RAIS, the system 
■was almost totally off from April to mid-Jime 1977. Even 
when all other subsystems are working fine, the inefficiency 
of the card reader increases the assembly time/compute time 
■very badly. 

Software 

The KDM worked satisfactorily. B/iL has also proved 
efficient in assembly and execution. Assembly language 
Programs use very small memory space, COPY routines did not 
work while creating an object tape from DISK, 

Due to lack of protection on the disc and inefficiency 


of the card reader, it is strongly recommended to users 
to create object program paper tapes during assembly for 
future input. 



